The present invention relates to methods and systems for accumulating call specific data for network communication traffic, including release cause information, and analyzing network troubles as well as traffic patterns encountering troubles, based on the call data.
The written description uses a large number of acronyms to refer to various services, messages and system components. Although generally known, use of several of these acronyms is not strictly standardized in the art. For purposes of this discussion, acronyms therefore will be defined as follows:
Automatic Message Accounting (AMA)
Address Complete Message (ACM)
ANswer Message (ANM)
Call Detail Record (CDP)
Carrier Identification Code (CIC)
Centi-Call Seconds (CCS)
Central Office (CO)
Competitive Local Exchange Carrier (CLEC)
Common Channel Interoffice Signaling (CCIS)
Common Language Location Identifier (CLLI)
Customer Record Information System (CRIS)
Destination Point Code (DPC)
End Office (EO)
Engineering and Administrative Data Acquisition
System (EADAS)
Global Title Translation (GTT)
IDentification (ID)
Initial Address Message (IAM)
Interexchange Carrier (IXC)
Integrated Services Digital Network (ISDN)
Internet Service Provider (ISP)
ISDN User Part (ISDN-UP or ISUP)
Landing Zone (LZ)
Line Identification Database (LIDB)
Local Area Network (LAN)
Local Exchange Carrier (LEC)
Loop Maintenance Operations Systems (LMOS)
Message Signaling Unit (MSU)
Message Transfer Part (MTP)
Minutes Of Use (MOU)
Multi-Dimensional DataBase (MDDB)
Number-Plan-Area (NPA)
On-Line Analytical Processing (OLAP)
Operations, Maintenance, Application Part (OMAP)
Origination Point Code (OPC)
Personal Computer (PC)
Plain Old Telephone Service (POTS)
Public Switching Telephone Network (PSTN)
ReLease Complete (RLC) message
RELease (REL) message
Service Switching Point (SSP)
Signaling Link selection Code (SLC)
Signaling System 7 (SS7)
Signaling Point (SP)
Signaling Transfer Point (STP)
SubSystem Number (SSN)
SUSpend (SUS) message
Structured Query Language (SQL)
Transaction Capabilities Applications Part (TCAP)
Wide Area Network (WAN)
An essential problem in optimizing a telecommunications network is balancing equipment and trunking against service, maintenance and cost. Network design involves predicting future demand based on past results, evaluating the capacity of equipment and facilities, and providing the correct amount of capacity in the proper configuration, in time to meet service objectives. Effective operation of a network involves recognizing troubles and congestion and implementing corrective measures. Virtually every element of a telecommunications system is subject to failure or overload. Effective testing, monitoring, control, and maintenance therefore is essential to obtain and maintain acceptable levels of performance and customer satisfaction.
Rapid changes and increases in demand for telecommunication services increase the pressures for cost effective engineering, maintenance and upgrading of the telephone network. Two examples of recent concern to local exchange carriers (LECs) relate to Internet access traffic and traffic to and from competitive local exchange carriers now commonly referred to as xe2x80x9cCLECs.xe2x80x9d
The sudden increase in popularity of access to the Internet, for example, has radically changed the loading placed on the telephone network. Normal voice telephone calls tend to occur at random times, and the network typically routes the majority of such calls to random destinations. Also, the average hold times for such calls tend to be short, e.g. three minutes. By contrast Internet traffic tends to have severe peak traffic times during any given twenty-four hour period, e.g. from 8:00PM to 11:00PM. Also, the network must route Internet access calls to a very small number of destinations, i.e. to the lines for modem pools operated by Internet Service Providers (ISPs). Instead of many parties calling each other randomly, many callers are all calling in at about the same time to a limited number of service providers. Finally, hold times for Internet calls can last for hours. Some Internet users access the Internet when they sit down at the desk and leave the call connection up until they decide to turn their computers off, e.g. at the end of their day. If they leave their computers on all the time, the connections to the ISPs may stay up for days. These lnternet traffic patterns add incredibly heavy traffic loads to the telephone network and tend to concentrate those loads in specific offices providing service to the ISPs.
To meet the new demands relating to traffic to and from a competitive local exchange carrier (CLEC), the LEC must provide tandem capacity and trunking to the CLEC exchanges. The CLECs demand that the LEC provide sufficient capacity to minimize blockages on calls to and from the CLEC networks. Disputes also arise over the amount and direction of such traffic, for example, as it relates to billing and compensation issues.
Adding end offices, specialized switching modules, trunks, tandem offices and the like to meet new demands such as those of Internet access and CLEC interconnection requires considerable expense. Accurate engineering, to minimize cost and yet provide effective service to the various customers, becomes ever more essential. To provide effective engineering, it is necessary that the LEC understand the traffic involved. Such understanding requires accurate and complete traffic measurement.
In particular, it is necessary that the LEC recognize causes of network troubles interfering with large volumes of traffic. For example, if a CLEC or ISP complains of blockages, and the blockages are due to overloading of the LEC equipment servicing the CLEC or ISP, then the LEC must design and deploy an upgrade of the LEC network specifically engineered to eliminate the cause of the blockages. If the LEC equipment was not in fact the cause of the blockages, e.g. if the ISP did not subscribe to enough lines and deploy enough modems, then any upgrade deployed by the LEC would actually be a waste of considerable time, effort and expense.
Existing operations and maintenance systems concentrate on responding to specifically reported troubles relating to individual lines or network elements. For example, U.S. Pat. No. 5,687,212 to Kinser et al. discloses a reactive maintenance system that analyzes the working status of customer network facilities in response to a customer request reporting a customer trouble. An attendant station receives the trouble report from the customer, and a test system initiates testing of the line associated with the trouble report. The reactive maintenance system also includes a work request processing and dispatch system, for dispatching field technicians to resolve identified circuit problems. While such a system is effective in resolving specifically reported line troubles, this system does not provide any overall picture of the traffic and congestion related troubles, such as reasons for high numbers of blockages on calls to a particular customer.
Attempts to use traditional approaches, such as the accumulation of data from the switches themselves and the Engineering and Administrative Data Acquisition System (EADAS), fell short of providing the desired information.
For example, one approach to a traffic analysis is to study usage in an office by setting up a xe2x80x9cbusy studyxe2x80x9d with respect to specific individual lines served through that office. However, it is not possible to look at all the traffic in the office at one time. Typically, the LEC can study maybe three different lines at a time. So in a 50,000-line office the LEC engineers can examine the traffic for up to three hundred lines at one time. Also, setting up and maintaining such studies are labor intensive. To conduct a meaningful number of busy studies throughout a large service area, a LEC virtually needs an army of clerical people whose main job function is setting up busy studies. Once set up, such a busy study may run for three weeks, but at the end of that time, it takes another two weeks to process the output and organize the results into a report. Results are not available in real-time. Even when results do become available, the study only shows data on a few lines that may or may not be causing blockage in the busy hour. If the lines were not properly selected, the busy study may be virtually meaningless to the network engineer trying to relieve congestion through the office. Traffic patterns are changing rapidly, e.g. as the CLECs"" customer base grows, as new ISPs obtain lines or as existing ISPs add new lines in already congested service areas. As a result, by the time that the engineer accumulates enough data for a meaningful study, the data may already be obsolete. Finally, the known network study techniques provide little or no ancillary information regarding causes of blockages of calls to the lines under study. As such, the available information relating to traffic problems affecting a high-volume customers"" service is limited, at best.
U.S. Pat. No. 5,475,732 Pester describes an SS7 Network Preventative Maintenance System for detecting potential signaling system seven (SS7) and switched network troubles, automatically analyzing the troubles, and providing alarm and corrective action to avoid major network events. The Pester SS7 Real Time Monitor System described in that Patent is a multi-stage SS7 network preventative maintenance tool that traps SS7 messages, detects potential SS7 and switched network troubles, automatically analyzes those troubles, and provides alarm and corrective action instructions to maintenance personnel. This too is a reactive approach intended to detect and correct existing problems with existing network equipment. The intent is to enable immediate corrective action with respect to an element causing or experiencing a particular problem.
U.S. Pat. No. 5,592,530 to Brockman et al. relates to an SS7 monitoring system for evaluating the operations of telephone switches by capturing data between signaling nodes of a telephone switching system. The Brockman et al. surveillance equipment captures signaling information from different signaling network paths within a mated pair of signaling transfer points (STPs) and correlates the fragmented messages for each monitored call. The system is capable of generating call detail records from the SS7 messages of a mated pair cluster, for use in billing and fraud detection.
While the above discussed Pester and Brockman et al. Patents describe the usefulness of monitoring an SS7 common channel interoffice signaling network for event detection, neither of these patents is directed to the particular problems of aggregate traffic measurement addressed by the present invention. The Pester Patent places emphasis on monitoring of the SS7 network itself in order to detect troubles in its functioning. The Brockman et al. Patent focuses on monitoring of all links to the STPs in a pair and the assembly of related SS7 signaling messages to form a record of call completions.
While these methodologies may be effective for their stated purposes there remains a distinct need for an efficient and effective tool for monitoring and analyzing types of traffic through the telephone network, to recognize and analyze volumes and patterns of network traffic and troubles at a high level rather than at a specific element level. Pester, for example, envisions immediate action to correct a fault, not measurement of traffic to show or forecast growth and increases on demand for services. There is still a specific need for a traffic analysis methodology to recognize choke points and other congestion related causes of common network troubles, particularly troubles encountered by certain types of dynamic high volume customers of a local carrier, such as other carriers and ISPs. There is a need for a traffic analysis tool, particularly for use in designing network upgrades, that analyzes overall traffic through a portion of the network and analyzes troubles in relation to the overall traffic patterns.
It is accordingly an object of this invention to provide a relatively low cost solution to those problems and needs.
It is another object of the invention to provide a timely, powerful, cost effective means of analyzing volume traffic flow through the Public Switching Telephone Network (PSTN) and blockages and other troubles encountered by such traffic.
It is a further object of the invention to provide a flexible, expedient, accurate, and cost-effective method to identify traffic factors and/or specific equipment contributing to network blockages.
The invention addresses the above stated needs by providing effective techniques for monitoring management data messages used by a telecommunication network during processing of calls through the network. For each call, at least one message comprises an item of information relating to the cause of release of a circuit involved in the call, for example a release cause code. The invention involves compiling detailed records of processed calls from the messages, and these records include the release cause information. Processing of the records enables analysis of troubles encountered by particular types of substantial call traffic through the network, based on analysis of the release cause information.
The call records are developed from monitoring or compiling of items of information from certain management data messages used by the network. Management data here refers to information generated by the telecommunication network for its operations purposes. The invention can utilize any such messages, so long as they include release cause information. An example of such data might be messages sent from central offices of the network to an accounting office, for record keeping and billing purposes, assuming that such messages include the necessary release cause information. The preferred embodiments involve monitoring of interoffice signaling messages generated to control call set-up and tear-down. For example, the signaling system seven (SS7) protocol specifically requires a release message during tear-down of each call. That message includes a release cause code.
Aspects of the invention encompass both methods and systems for accumulating the necessary call data from monitoring of the network and analysis of the call data with regard to the traffic troubles and patterns thereof.
Thus, a first aspect of the invention relates to a method that analyzes network troubles based on release cause information accumulated from monitoring of the telecommunication network. Specifically, this method involves capturing management data messages generated by the network during call processing. At least one of the management data messages generated during the processing of each call specifies a release cause. From the messages, the method compiles a detailed record of each call. Each call record includes a specified release cause. The specified release causes in the detailed records are processed in order to form aggregate data. The aggregate data indicates troubles encountered in processing of patterns of call traffic through the telecommunication network.
Examples of patterns of call traffic include calls through a particular office of the network, all calls of a particular type through one or more offices, etc. Specific patterns of interest include calls for Internet access and calls to or from a CLEC network.
The preferred embodiment of the method relates to analyzing troubles encountered by call traffic processed through a telephone network. Here, the method involves monitoring interoffice signaling messages communicated between offices of the telephone network during processing of each call. At least one of the messages communicated during the processing of each call comprises a release cause code. Detailed records for a set of calls are compiled from the monitored messages, and each of these records includes a release cause code specifying a reason that the telephone network did not complete a respective call. The inventive method involves processing the release cause codes in the detailed records, to form the aggregate data indicative of troubles preventing the telephone network from completing calls.
The analysis of release cause codes using aggregate data provides information relating to troubles encountered in high volume traffic flows and patterns of call processing through the telephone network. The analysis of release causes for uncompleted calls provides a tool for long range maintenance and upgrade planning. For example, such an analysis clearly shows locations and causes of congestion relating to certain patterns of traffic. This enables the engineer to design and deploy changes or new equipment in the network to best address the underlying cause of congestion impacting on significant types of customers and services, corresponding to the traffic patterns.
The invention emphasizes analysis of traffic and patterns for engineering, congestion relief and other purposes, as opposed to the detection of individual faults for immediate corrective action as was the case in the past.
Another aspect of the invention relates to a traffic tracking system. The system includes a monitoring system, for association with a switched telecommunication network. The monitoring system monitors management data messages communicated during processing of calls by a switched telecommunication network. At least one message generated during the processing of each call specifies a release cause. In an embodiment that monitors a telephone network, for example, at least one message regarding each call is a release message that contains a release cause code. A processor compiles detailed records of processed calls from the monitored messages. A database stores the detailed records of calls in a table. An on-line processing system aggregates data indicative of troubles encountered by call traffic processed by the switched telecommunication network from the database table.
In the preferred embodiment, the traffic tracking system also includes a data preparation routine. The database receives and stores detail records of selected calls processed through the network. The data preparation routine operates on files in the database, to enrich the detail records in a predetermined manner corresponding to a running study. The preparation routine, for example, may convert release cause codes from the detailed records to descriptions of the release causes. As another example, this routine may translate information in the records into identifications of offices processing the calls, preferably including any offices that caused releases for uncompleted calls.
The on-line analytical processing routine receives the enriched call detail records from the data preparation routine. An application, running on the on-line analytical processing routine, processes the enriched call detail records in accord with the study.
In the preferred embodiment, the on-line analytical processing program comprises a multi-dimensional database and implements a web suite type user interface, for analyzing and accessing the study results. The data preparation system uploads an expanded table containing the records with the enriched information. The data preparation system may generate one or more summary tables, for use by a particular study application running in the on-line analytical processing system.
The inventive system may provide traffic tracking for any of a variety of different types of networks. However, the preferred embodiments track traffic for trouble analysis of calls through a switched call processing network, such as a local carrier""s network of the public switching telephone network. Such a network includes switching offices, providing selective call connections to links serving subscribers. Many such networks produce a variety of call management data messages for normal call processing and/or accounting, which may be monitored or accumulated for use in the traffic tracking studies of the present invention. The preferred embodiment monitors common channel interoffice signaling messages, which typically contain cause codes identifying release causes exemplifying the causes of network troubles.
In this regard, the preferred embodiments of the present invention utilize real time monitors on selected SS7 links to collect out-of-band interoffice signaling messages. A site processor compiles data from the signaling messages relating to individual calls, to form call detail records (CDRs) for all interoffice call attempts. The site processor uploads the CDRs to a central server. The server maintains the relational database for the CDRs derived from the signaling data. Data from the relational database is processed or xe2x80x98preparedxe2x80x99 and uploaded to the multi-dimensional database. The multi-dimensional database provides the on-line analytical processing tools for enhanced processing of the call data and offers an efficient graphical user interface, preferably a web suite type interface.
Data mining technologies allow for detection of subtle network conditions traceable through CDR release data. Unique release patterns point back to subtle problems in the network.
Additional objects, advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The objects and advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.